Creating a User

Configuration for your client. Allows client to set their ID and decide which backend environment to point the SDK at.

This is the first structure you must create in your SDK. Typically, an application will have one for testing/debugging purposes and one that is used in a production environment. A tip for organizing them would be to have it globally available in your applications:

extension ClientConfiguration {
  static let debug = ClientConfiguration(
    ...
  )

  static let production = ClientConfiguration(
    ...
  )
}

API calls will NOT work accross different ClientConfiguration objects. If you have state that is left over after using one ClientConfiguration, and then you try and use that state with a different ClientConfiguration, you will not get the results you want.

This object is used to set your ClientConfiguration.Environment, your ClientConfiguration.appURLScheme and your locale.

App URL Scheme

If you want deep linking to work, then you must specify your app’s URL scheme as well. For Schibsted account mobile clients, the scheme is fixed and is available from the Schibsted account Self Service.

You should specify this string value when creating your ClientConfiguration and you should also register the url scheme as per Apple guidelines.

See more

public struct ClientConfiguration

This manager provides access to various auth related APIs and manages the creation and persistence of an internal User object that can be accessed through IdentityManager.currentUser.

A number of methods of creating a user exist within this manager. They include:

1. Passwordless login APIs (IdentityManager.sendCode(...))
2. Password login APIs (IdentityManager.login(...))
3. Signup APIs (IdentityManager.signup(...))
4. APIs to access client specific information

The general approach is to first create an IdentityManager with a ClientConfiguration. After that you may check if there already is a user that was previously persisted. This can be checked via IdentityManager.currentUser‘s User.state which will tell you if the internal user is in a logged in or logged out state. In order to comply with privacy regulations, you also need to make sure that the user accepts any update to terms and conditions that may have been issued since the user’s last visit: see User’s documentation for more details on how to do that.

The objective of the identity manager is to create a user object. There should be no need to keep an identity manager lying around once you have a reference to the internal user object.

Authorization code vs one-time code

There are two code validation APIs in the manager. One of them operates on one time codes that are explicitly send to an Identifier using IdentityManager.sendCode(...) to start a passwordless login process. The other is an OAuth-related authroization code, which is not explicily requested. The current use-case for authorization code validation is after a signup process, when a user verifies their email. Or after an unverified identifier tries to login.

After logging in

After you successfully login by either the passwordless or password APIs, it is recommended that you check the profile status of your user object. This means checking if there are updated terms and conditions that need to be accepted or if there are required fields that need to be updated. These can both be done via User.Agreements.status(...) and User.Profile.requiredFields(...).

User persistence

If the persistUser parameter passed to the IdentityManager’s methods is true, the user that is internally managed by an identity manager is also persisted in your keychain for maintaing logged in and logged out state. Therefore, once a user is made valid, the manager persists the data necessary to recreate the user for a later session.

Currently the keychain user is a singleton. So the last user that is validated will be persisted. And the last user that is persisted will be the one that is loaded by a new instance of the IdentityManager.

Scopes

Some of the functions take a scope parameter. This is related to OAuth scopes. If you want to add the ability to specify custom scopes or you want access to some already available predefined scopes, then you’ll have to send a support request to schibstedaccount@schibsted.com

Support

The visual login via the IdentityUI is the recommended approach to creating a User. This IdentityManager should just be used to check if there’s already an existing user.

See more

public class IdentityManager : IdentityManagerProtocol

This is the main IdentityUI object that can be used to create a user object via a UI flow.

There are two ways to start a login process, you can either start the flow from the beginning which will be presented on a provided UIViewController, or you can provide an IdentityUI.Route that is generally used to continue a flow from the deep link.

See more

public class IdentityUI

The user object is the central part of the SDK. Once one is created, it is recommended to hold on to it until you do not need it anymore.

There are 2 ways to create a valid user object currently:

1. Through the IdentityManager
2. Through the IdentityUI

It is recommended that you create one using the provided UI flows. But if the need arises the headless approach is also documented, but not officially supported.

Checking if you have an already logged in user

The process to check that is currently supported by the IdentityManager.currentUser object. Once an identity manager is initialized, it’s internal user object is either in a logged in state or not.

Based on the state of IdentityManager.currentUser, you may either proceed to get one or store it and use it for whatever else.

In order to comply with privacy regulations, you need to make sure that the user accepts any update to terms and conditions that may have been issued since the last visit. For this reason, at the startup of your app, right after having obtained the IdentityManager.currentUser and verified the login status, if the user is logged-in you should call user.agreements.status(:) and, in case of false result (meaning the user has yet to accepted the latest terms), obtain the latest terms by calling IdentityManager.fetchTerms(:) and finally present a screen where the user can review and accept the updated terms. The recommended way of presenting the screen is by using the provided UI flows, thus by callingIdentityUI.presentTerms(for:from:)`.

If you are using the headless approach instead, you should then present your own UI and manually call user.agreements.accept(:), if the user accepted the new terms, or logout(), if the user rejected them.

See more

public class User : UserProtocol

User object delegate to be notified of changes

See more

public protocol UserDelegate : AnyObject

Possible states that this user is currently in.

See more

public enum UserState : Int, CustomStringConvertible